The present invention relates to a method for managing a communication between a server device and a customer device, and such a server device and a customer device.
Such a server device, customer device and method are known from the European Patent application with Publication number EP1931099 being published dd. Nov. 6, 2008 and from the DSL-Forum that has defined the Customer Premises Equipment Wide area Network Management Protocol, shortly called the WAN Management Protocol in the Technical Report TR-69. This TR069 Management Protocol is intended for communication between Customer Premises Equipment and an Auto-Configuration Server, shortly called an ACS. The version of May 2004 of this Technical Report TR-69 is to be found at www.dslforum.org.
The Technical Report TR-69 document describes at page 9, paragraph 1.6 the commonly used terminology. The following definitions are relevant for the further reading of this applications.
The ACS is an auto-configuration Server, as the component in a broadband network responsible for auto-configuration of the CPE for advanced services. The CPE is the Customer Premises Equipment whereby a B-NT is a broadband access CPE device capable of being managed by and ACS and being one form of a broadband CPE.
An RPC is a remote procedure call, whereby a “parameter” defines a name-value pair representing a manageable CPE parameter made accessible to an ACS for reading and/or writing.
In this way the TR069 Management Protocol defines a mechanism that encompasses secure auto-configuration of a CPE, and also incorporates other CPE management functions into a common framework. The TR069-Management protocol makes use of these Remote Procedure Calls—RPC Methods that defines a generic mechanism by which an ACS can read (get) or write (set) Parameters to configure a CPE and monitor CPE status and statistics.
At page 12 paragraph 2.3.1 of TR069 the Parameters are discussed more in details. There it is described that an RPC Method Specification defines a generic mechanism by which an ACS can read or write Parameters to configure a CPE and monitor CPE status and statistics. Each parameter consists of a name-value pair. The name identifies the particular Parameter, and has a hierarchical structure similar to files in a directory, with each level separated by a “.” (dot). The value of a Parameter may be one of several defined data types. Parameters may be defined as read-only or may be defined as read-write. For some predefined objects, multiple instances may be defined. The individual instances are identified by an index number, assigned by the CPE.
A method is described for managing a communication between a server device e.g. and ACS and a customer device e.g. a CPE that comprises the steps of interchanging between the server device and the customer device one or more parameter messages such as e.g. a GET message, comprising a parameter description for a parameter name. The parameter description is consisting of a hierarchical tree-like structure of characters with each level separated by a predefined character (dot).
It has to be explained that interchanging such kind of messages is described in the TR-069 document at page 12 in paragraph 2.3.1 that describes the parameters. There it is explained that the parameters may be defined as read-only or read-write. Read-only Parameters may be used to allow an ACS to determine specific CPE characteristics, observe the current state of the CPE, or collect statistics. Writeable Parameters allow an ACS to customize various aspects of the CPE's operation. All writeable Parameters must also be readable. The value of some writeable Parameters may be independently modifiable through means other than the interface defined in this specification (e.g. some Parameters may also be modified via a LAN side auto-configuration protocol).
An example of a parameter is hereafter described in an abstract way. The name of the parameter is called e.g. “C” in a parameter-tree A.B.C.Instance_C.D. Presume that there are actual100 instances for C existing on the CPE device and four values D1, D2, D3 and D4 parameter D. The 100 instances of parameter C are described in a next level i.e. Instance_C in the parameter description. The ParameterValue pairs on the device are then e.g.:    1)    A.B.C.1.D1=Val_D11    A.B.C.1.D2=Val_D12    A.B.C.1.D3=Val_D13    A.B.C.1.D4=Val_D14    2)    A.B.C.2.D1=Val_D21    A.B.C.2.D2=Val_D22    A.B.C.2.D3=Val_D23    A.B.C.2.D4=Val_D24    . . .    100)    A.B.C.100.D1=Val_D1001    A.B.C.100.D2=Val_D1002    A.B.C.100.D3=Val_D1003    A.B.C.100.D4=Val_D1004
In the event when the ACS is interested in the name of “C”, but however, doesn't know the number of “C” instances, the ACS can retrieve the information according to two 2 ways which are described her below.
1) A first way to retrieve the parameters, the RPC-method “GetParameterValues” is used, but since the ACS doesn't know the number of instances in the array, a method with two steps with dynamic arrays is used.
    Firstly the ACS sends the message “GetParameterNames” with next level on true:    GetParameterNames(“A.B.C.”, nextLevel=true)    Hereby the CPE sends the response with:    GetParameterNamesResponse(“A.B.C.1”, “A.B.C.2”, . . . , “A.B.C.100”).In a second step, with this received response from the CPE, the ACS can construct the message GetParameterValues and transmits this request again to the CPE:    GetParameterValues(“A.B.C.1.D1”, “A.B.C.2.D1”, “A.B.C.100.D1”),The CPE generates the response:    GetParameterValuesResponse(“A.B.C.1.D1”,“Val_D11”,“A.B.C.2.D1”, “Val_D21”, . . . , “A.B.C.100.D1”,“Val_D1001”).
According to this first way, the parameter name argument is given as a full parameter name, and only the individual parameter value is returned.
A drawback of this first approach is that the ACS only learns the answers after two roundtrips of question/answer.
2) A second way to obtain the parameter values is immediately with the message GetParameterValues but with an incomplete path ending with a dot:
    GetParameterValues(“A.B.C.”). The response from the CPE comprises:    GetParameterValuesResponse    (“A.B.C.1.D1”,“Val_D11”,“A.B.C.1.D2”,“Val_D12”, “A.B.C.1.D3”,“Val_D13”,A.B.C.1.D4”, “Val_D14”, “A.B.C.2.D1”,“Val—D21”,“A.B.C.2.D2”,“Val_D22”,A.B.C.2.D3”,“Val_D23”,A. B.C.2.D4”,“Val_D24”, . . . , “A.B.C.100.D1”,“Val_D1001”,“A.B.C.100.D2”, “Val_D1002”, A.B.C.100.D3”,“Val_D1003”,A.B.C.100.D4”,“Val_D1004”)
According to this second way, the parameter name argument is given as a partial path name whereby the request is to be interpreted as a request to return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. A partial path name must end with a “.” (dot) after the last node name in the hierarchy.
A drawback of this second approach is that the ACS receives too much information besides the values for the distinct parameters it needs to know.
So, the existing solutions provide a lot of load over the network and generate implementation complexity on the ACS. Since the ACS is dealing with millions of devices, scalability becomes with these solutions a concern in any ACS implementation. Latency and too much response time are introduced.
Whenever an array of objects must be retrieved, the second approach (i.e. partial path names) must be chosen. An example of such an array of objects is e.g. the state changes of different UPnP-devices in a home network such as a combined remote sensing instrument to measure temperature, humidity (hygrometer) and illuminances (lux-meter) or the state changes of an alarm detector in a home network, This second approach works well for the case that all underlying array objects need to be retrieved. For the more specific case when only a range of objects is of interest, the protocol doesn't define any range-restriction facilities. If a parameter-sub-tree such as described above for A.B.C. contains X underlying parameters, 100*X parameter values needs to be returned to the ACS. In many cases, this is not desired because:                The ACS is only interested in a sub-range (e.g. 50 . . . 100)        The ACS is only interested in new entries (e.g. new entries from 80 on)        The whole set of returned parameters might generate an inappropriate bandwidth usage burst and therefore compromise scalability on the ACS side.        